Being brought in to create content on a very mature project has been an interesting experience to say the least. One of the first things I did was analyse the features of the game and which kind of player the game currently supports. The obvious thing is that Factorio Freeplay strongly attracts and engages players who enjoy an open-ended sandbox type of game. Achievement statistics show that only about 11% of players on Steam have ever launched a rocket, which currently means 'won the game'. What about the other player types? Well for those that are new to the game, or unsure if they are interested, we will have the New Player Experience. This is a free, combined tutorial and demonstrator mission which we discussed in FFF-241. But what about those that prefer a guided experience? This is the sort of player who wants to play the game, and experience all of what it has to offer, but wants to be taken on a journey. For these players we have the campaign. Why do we need a new campaign at all? We find that the current campaign: Does not include all the Freeplay content as it currently ends after Advanced Circuits. Severely limits player investment by forcing a new factory to be built each mission. Does not convey the feeling of loneliness that the Freeplay does. Is showing its age visually, as it was made before high-res textures and the terrain rework. To solve these issues we have set about designing new Campaign elements to act consistently to provide the player with a guided experience all the way from Science pack 1 to Space science packs. The first step to achieving this is to have the map border expand each time the player completes a section of the main 'quest line'. This means that the player never loses any of their progress, and as long as these transitions are presented in a smooth way, the jarring effect of the old level restarts will be removed. Having a continuously expanding map presents many other challenges, but we are confident that it will be worthwhile. This style of level will fit with the style of Factorio much better. Such a map should also end up being as huge as a regular Freeplay environment so as to better place importance on exploration. Exploration in Freeplay is generally player motivated, such as when you are almost out of iron and need to find that next big patch. In a guided experience, letting the player know that there is something out there can give them impetus to dive into the unknown. This brings us to technologies. Now that we have removed level transitions, we have also shot ourselves in the foot. How else will we deliver the technology tree in chunks? Simply making the entire tree available from the start of the game will cause all sorts of balance issues. In our NPE discussion we stated that new recipes should only be given to the player via research. In the campaign, unresearched technologies will only be given by moving to given locations on the map. These would include some non-generated terrain and pre-placed factory structures to help to player see where they are. These could also help to show concepts and workable designs, one thing that the current campaign does do well.

New player experience (V453000 & Abregado) In the last several weeks/months we have been working on deciding the fate of the campaign and the demo/tutorial missions. Hi, I'm Ben (Abregado). My experience as an educator using Factorio in the classroom means I have thoroughly examined new players (young and old), and have played the first 30 minutes of Factorio for as many hours as some players spend on a single megabase. The systems in Factorio are deep and interconnected, so creating an onboarding experience for a single concept poses many exciting challenges. We find that the Freeplay portion of the game is already enjoyable to its target audience, but those who prefer a more guided experience only get a short campaign which doesn’t even utilize all of the features we’ve added to the game. On top of that brand new players need to dig through a tutorial which takes about 30-45 minutes to get to automation, which is what the game is about. We want to keep the demo so that anybody who wants to try the game can do it for free, and get a proper representative introduction to what Factorio is. For Factorio, the demo should serve a dual purpose of a tutorial and a teaser, both of which we feel could be improved... Currently we find the demo has the following problems: The impact of the first level isn’t very visually representative of what Factorio is. Gives the impression of being a Minecraft clone in the first tutorial mission by having to mine manually and do hand crafting. Key concepts like Assembling machines and electricity are not presented for the first two levels. Player actions are so heavily constrained that the player learns just how to solve the tutorial rather than learning the concepts we are trying to demonstrate. Each of the levels is disconnected from the previous. Which item recipes are available, that there are suddenly built structures and the location is completely different. Grindy tasks like obtaining X resources in 2nd tutorial mission don’t have any clear purpose. The player does it because they are being told to, not to achieve some other goal that would make sense in the progression. A lot of information is not important and just floods the player with noise, for example many of the messages. The places where the player gets information are scattered - Objective window in the top left, the player character talking to themselves in the console chat and the yellow "TAB bubbles". The three different information channels competing for attention. In this case also two of them telling you the same self-explanatory information (where is the current objective shown, if you didn’t get it), while the chat informs you that your character is alive. A typical objective without purpose. (I guess the game will tell me what is it for soon?) Doesn’t this message resemble another game? What we would like to achieve with the new design: Create an immediately gripping environment that better sets up the Factorio feel. Showing and teaching core concepts like Assembling machines and electricity in the first level using as little complexity as possible. Providing goals through the technology tree, working with laboratories and the technology GUI as soon as possible. Standardize the way players obtain new items. Every recipe has to be obtained through a technology - that way the player triggers recipe progression and gets them as a reward. Starting a new level should start the player at a similar progression state where the previous mission left off. Teaching by experimentation instead of jumping through arbitrary tasks. Letting the player coming up with their own solution of a puzzle. Unify the channels the player gets information from (mostly GUI improvements). After finishing the demo, the player should be ready to continue by playing the main campaign, or jump straight to the Freeplay. If you had to pick one entity that represents the game to you the most, which one would it be?

Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.

Hello dear biters and related species from unexplored planet full of life and natural resources. Recently I have been working on several high resolution graphics for your best friends - the tank and the player character. In this article I would like to show their updated visuals to you, as well as a sneak peek at how they are produced. The following text may contain traces of automation.

It’s been several weeks since we showed you the graphics for new high resolution circuit connector modules (FFF-202). However now is finally the time when we have them in the game. In this article I will briefly show you what was done both in the graphics and code, and what new benefits are there for you as players and modders. I find the 0.15 version of the circuit connector module has following “problems”: The wire connectors are different from the combinators. Wires sometimes completely overlap, making only one of them properly visible. Modularity - you can somewhat tell what is happening based on the LED states, but it could be much nicer. Connecting a belt always looks weird, while the yellow structure which holds the connector box could be made more specific. Some of the rotations are utterly useless. The Lua definitions are spread over every single entity, so revisiting them all is a big pain.

Hello inhabitants of a remote and unexplored planet full of life, richness and natural resources. The group of entities we are bringing to high resolution currently is the combinators. The main problem with them is the amount of shifting values needed, so we used a specific workflow which I will try to show and explain today. Some of the parts have already been described in FFF 146, so I will only mention what is necessary for this article. Please fasten your belt as this will be a ride full of automation.

Hello, it has been a pretty hot week here in Prague, and we have finally wheeled-out and hooked-up our little air-conditioning unit, which has been making a valiant effort to keep the office cool.

Space science As you already know, in 0.15 we have reworked the science packs and added infinite science. More and different science packs make the game a lot more interesting. It reduces the complexity of blue science (which is great for newer players) while adding complexity later, and you now have to decide what to research first, especially with the more expensive game modes (which is interesting for advanced players), and infinite science adds something to do forever in the game. However, one of my biggest complaints about Factorio always was that the rocket has no purpose, even though it is being propagated at all the points as the final step of the game. It is said at the trailer, at the introduction of freeplay, and by being the most advanced research, everything seems like it’s the thing to desire, but when I launched it for the first time and seeing the victory screen, I was feeling like "And now what...". For me there is one main reason why Factorio is so awesome and why I can forget myself playing until 4 a.m., and that reason is the infinite loop of 'there is always a bottleneck', you always need to fix something, you have not enough power, or your production of a particular product is insufficient etc. When you launch the rocket, you escape from this loop because it doesn’t lead anywhere. As we can see, we have learned to take the rocket as a measurable resource sink to quantify the size of our factories, which is great, but I think it makes sense to us only because we got used to it, not because it made sense in the first place, or at least it didn’t to me. Now when 0.15 adds infinite research, I started to ask myself why would I launch the rocket at all, and I have seen many of you ask similar questions. To compare the two, the infinite science is also quantifiable as I can see the amount I produced in the production screen, it also has an interesting crafting recipe (rocket parts vs. all science packs together), and it is also an infinite resource sink. The main difference is, the infinite research is actually useful. This is where the space science comes into play. We now have a space science pack, obtained by launching a rocket. You get 1000 of these science packs per rocket, and every infinite research requires these science packs. Such a simple feature, but it closes the infinite game loop again. But of course in case you want to just launch rockets without worrying about science, you can still do that, just like previously. We have also added more infinite researches, so now apart from worker robot speed, combat robot follower count and mining productivity bonus researches, we also have all of the combative damage upgrades infinite (not shooting speed as that would get ridiculous sooner or later), however their prices increase exponentially to prevent it from getting too extreme. The rocket has to have a satellite in order to get the science packs (the rocket has to be able send back the discoveries, right?). The rocket silo now has an auto-launch checkbox so you can launch them automatically, and the launch is only going to happen when you insert satellite. So you can control the inserter with satellite to only launch rockets when you need the science packs automatically through circuit network. Of course we also added support for mods, so you can define what do you get from sending a rocket, and depending on what you put in the rocket - say, if you put a tank into the rocket, you receive 100 raw fish, because that would make perfect sense. We can build up on this concept in the future, but for now this already brings a lot of sense to the game as it is. As a bonus, here is a album of my factory where I tested the infinite science concept.

Work this week has been progressing nicely on 0.15. We hope we will be able to start our internal play testing soon, as the team works to close off the rest of the major features. Rseding will be arriving here in Prague next week for another of his infamous visits, and Harkonnen will be joining us shortly after, so the office will be prepared for tackling any issues that may arise. Since we are going to be spending the next period polishing and fixing what we already have, you can look forward to some less interesting FFF posts in the coming days. Take the lack of exiting new topics to cover as a good omen that the whole team's effort is on getting everything ready for the release.

While all us minions and assembling humans are furiously working on 0.15, today I would like to present to you what I have been working on lately - new graphics for resources, of course including high res and the new uranium ore. In the second part of the article I will get to an old/new topic about concrete.